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■ 

Abstract. The congestion control algorithm in TCP relies on correct feedback from the receiver to determine 
04 \ the rate at which packets should be sent into the network. Hence, correct receiver feedback (in the form of ac- 

■ knowledgements in TCP) is essential to the goal of sharing the scarce bandwidth resources fairly and avoiding 
congestion collapse in the Internet. However, the assumption that a TCP receiver can always be trusted (to gen- 
erate feedback correctly) no longer holds as there are plenty of incentives for a receiver to deviate from the pro- 

■ tocol. In fact, it has been shown that a misbehaving receiver (whose aim is to bring about congestion collapse) 
can easily generate acknowledgements to conceal loss and drive a number of honest, innocent senders arbitrary 

1 i , fast to create a significant number of non-responsive packet flows leading to denial of service to other Internet 
' users. We give two efficient, provably secure mechanisms to force a receiver to generate feedback correctly; any 

incorrect acknowledgement will be detected at the sender. The first scheme is based on an ideal cryptographic 
hash, and the second one on aggregate authenticators. We also show variants of the second scheme which can 
(partially) solve the problem of man-in-the-middle attacks, which is not achievable previously. 

1 Introduction 

oo : 

The congestion control algorithm [ 16] of TCP (Transmission Control Protocol [22]) is an essential com- 
ponent contributing to the stability of the current Internet. It allows fair sharing of the scarce bandwidth 
resources and avoids congestion collapse in the Internet. However, it has been found vulnerable to incor- 
rect feedback from a misbehaving receiver by Savage et. al. E51 and subsequently by Sherwood et. al. 
ll26l . More specifically, when a misbehaving TCP receiver generates optimistic acknowledgements (ac- 
knowledging the receipt of TCP segments which have not been received), the sender of the TCP session 
. could be deceived into believing a fast connection is available and injects more packets into the network 

(through increasing its TCP flow window and sending new packets) despite that the acknowledged TCP 
segments may have been lost in a heavily congested network. Note that the stability of the Internet relies 
on TCP senders to back off their traffic when congestion occurs as inferred by packet loss 1161111 . 

The TCP congestion control algorithm 116122121 was designed based on the assumption that a TCP 
receiver can always be trusted [9] and all his feedback in the form of acknowledgements HI for correctly 
received packets is a reliable source of information about the traffic/congestion condition in the network. 
When network congestion occurs at some routers in the network, packet dropping starts to occur at the 
input queues of the congested routers. The design of TCP congestion control algorithm considers packet 
loss as the onset of congestion somewhere in the network 116122121111 . The TCP sender thus slows down 
its rate of injecting packets into the network (through multiplicatively reducing its TCP flow window 
and slightly inflating its timeout timer) with a view to relieving the congestion condition. However, the 
information of packet loss is usually provided by the receiver in the form of acknowledgements [1J. When 
this information is false, the TCP sender may respond to a network congestion in the oppositive direction 
leading to non-responsive traffic flows which cause other honest TCP users to back off their traffic. These 
non-responsive flows, in essence, form a type of denial of service attacks, as first identified by Floyd et. 
al. ifTTj and subsequently illustrated by Sherwood et. al. ll26l . The effect of such non-responsive flows 
can easily be multiplied by a deliberate attacker using a small TCP segment size ll24l . More seriously, 
subtle attackers can exploit this vulnerability of TCP to bring down the operation of the Internet by 



pumping in an enormous amount of traffic through a distributed network of malicious TCP receivers. In 
fact, Sherwood et. al. has shown the possibility of bringing terribly extensive network congestion over 
a prolonged period using such an attack [26]. Puzzle-based defence 11281 could possibly limit the rate at 
which a single server/sender injects traffic into the network; but this still cannot restrict a malicious TCP 
receiver from attracting traffic. Note that a TCP receiver can acknowledge a whole window of segments 
using just a single acknowledgement. A clever attacker can open many TCP sessions with different 
servers, requesting large files; while each of these servers may only sends data at moderate rates, all 
these flows converge toward the attacker and the resulting traffic aggregate (from all the servers) could 
be large and overwhelm several en-route routers close to the attacker. The non-responsive nature of these 
flows can make the congestion situation equally bad. 

Despite the serious impact which could be brought about by an attacker-manipulated set of misbe- 
having TCP receivers (whose goal is not merely to obtain faster downloads but instead to exploit this 
TCP vulnerability to mount a distributed denial of service attack against the entire Internet), there lacks 
a rigorous study and modeling of the security goal against malicious TCP receivers. As a consequence, 
it is fair to say the effectiveness of the existing solutions 1125 1261 remains uncertain. While most of the 
existing solutions emphasize backward-compatibility (as the most desired property), we adopt a clean- 
slate approach in this paper with provably secure solutions. For a detailed explanation of the rationale 
and importance of adopting a clean-slate approach to secure the Internet, ||6| provides a good reference. 
All the solutions proposed in this paper are provably secure |[T8l in the sense that any breach of secu- 
rity found in the proposed solutions can be traced back to a vulnerability in the underlying primitive 
(which is widely assumed to be secure), meaning the insecurity of the latter is the only cause for the in- 
security of the former. However, our solutions require modifications on both TCP senders and receivers. 
Nevertheless, no modification to the core functionality of the congestion control algorithm of TCP is 
made in our solutions; changes (in our solutions) will only be incorporated into codes for handling TCP 
acknowledgements and session management specified in RFC 793 |[22l . 

We address the security problem caused by a misbehaving TCP receiver using an approach which 
forces the TCP receiver to prove the receipt of segments based on cryptographic tools. We call the 
protocol a verifiable segment receipt (VSR) protocol. In a VSR protocol, a TCP receiver has to generate 
some proof to convince the sender that all the packets he claims to have received are actually received. 
The proof is constructed from the received segments and the attached tags generated by the sender. When 
a misbehaving TCP receiver wants to lie about the receipt of a certain TCP segment he has actually not 
received, he will not be able to create (without the knowledge of the lost segment and its tag) a valid 
VSR proof (acceptable by the sender) even though he may possess the data being transferred (through a 
prior downloadlj; in other words, a malicious TCP receiver cannot launch a playback attack, namely, he 
cannot generate a valid VSR proof for a lost segment in the current session even though he has complete 
knowledge of the payload of that segment. All forged proofs (for segments not received) will be caught 
by the sender which can then terminate the associated TCP connection. We propose two VSR protocols, 
one based on a cryptographic hash function and the other based on an (additive) aggregate authenticator 
f7l . These two protocol are provably secure based on two different sets of assumptions: the first one is 
secure assuming the underlying cryptographic hash function behaves like a random function whereas the 
security of the second one is based on the indistinguishability property of a pseudorandom function fl4l . 

It should be emphasized that the VSR protocol addresses a problem different from that of remote 
integrity check [ 8 ] or proof of retrievability II17I31 . Solutions of those problems cannot be applied directly 
to solve the problem of misbehaving TCP receivers; neither can VSR solve those problems. There are 

1 An attacker may have knowledge of the payload of the concerned TCP segment through prior downloads from the same 
sender/server. However, in VSR, the actual TCP segment is designed to be different for each new session even though the 
payload may be the same. 



two subtle differences. First, VSR has to guard against playback attacks in which the attacker possesses 
the data being transferred; while a prover in possession of the stored file can definitely produce a valid 
proof in the proof of retrievability scheme. Second, a receiver only needs to generate a proof once (in the 
current session) for each piece of data received in VSR0 whereas several executions of the verification 
protocol for the same piece of data in a proof of rettievability scheme are expected. 

We also address the problem of man-in-the-middle attacks in this paper. As discussed in (251, a 
man-in-the-middle attack in the context of misbehaving TCP receivers is difficult to guard against. In 
a man-in-the-middle attack, a malicious TCP receiver install some agents close to the sender. These 
agents may even reside in the same local network of the sender. These agents can process eavesdropped 
TCP segments and the attached tags, and sends the receiver a concise data structure which allows him 
to generate valid acknowledgements to pass the verification at the sender. These agents might even ac- 
knowledge the receipt of segments on behalf of the actual receiver. Since these agents are close to the 
sender, they normally receive TCP segments with a much shorter delay than the actual receiver does, thus 
easily giving the sender a false impression that a fast connection is available. We propose two solutions 
to (partially) solve the problem of man-in-the-middle attacks based on two different intuitions. In the first 
solution, we assume that there exists some trusted network entity geographically close to the receiver; 
this entity could be the firewall or network gateway of the local autonomous system wherein the receiver 
resides; this trusted network entity needs to pre-process VSR tags using a secret key shared with the 
sender in order to allow a receiver to generate valid proofs. In the second solution, we assume that each 
receiver is associated with a pair of public-private keys which the sender can verify; the receiver's private 
key is necessary for the generation of a correct VSR proof and is needed in the processing of each TCP 
segment; the agents are thus helpful to an attacker only when they are given the attacker's private key, 
which may be risky to the attacker since successful agent detection would completely reveal his private 
key; we hope this would hinder the attacker from using a man-in-the-middle attack. 

Contributions. The contributions of this paper are three-fold: (1) A formal treatment to the security 
problem of malicious TCP receivers is given; (2) two provably-secure protocols to solve the problem are 
proposed and the proposed protocols are reasonably efficient to be incorporated into the TCP protocol; 
(3) two solutions are proposed to (partially) solve the man-in-the-middle attack problem in which the 
misbehaving TCP receiver has some agents installed close to the sender to help it deceive the sender; 
to the best of our knowledge, we are the first to provide solutions to the problem of man-in-the-middle 
attacks in the context of misbehaving TCP receivers. 

The organization of the paper is as follows. A formal security model, along with possible security 
notions for VSR, is given in Section|2] Section [3]presents the two VSR protocols proposed and section|4] 
shows two variants of the VSR protocol given in section [3721 which defend against the man-in-the-middle 
attacks. 

2 Security Model for Verifiable Segment Receipt (VSR) Protocol 

Recall that our defence against a misbehaving TCP receiver is based on the idea requiring a TCP receiver 
to prove to a sender that it has received all the TCP segments it claims. We call this protocol a Verifiable 
Segment Receipt (VSR) protocol. More specifically, the TCP sender attaches some information as tags to 
segments sent whereby the TCP receiver can construct a proof from the segments and the corresponding 
tags received; the proof is then returned as part of the TCP acknowledgement for the sender to verify; 



2 In VSR, a new instantiation will be executed for a new session even for the same piece of data. 



in a properly designed scheme, a misbehaving receiver (which claims the receipt of segments it actually 
has not received) can only pass the sender's verification with negligibly small probability. 

For the sake of clarity, we defer the discussions on man-in-the-middle attacks and the proposed 
defence mechanisms to Section HI 

2.1 Definitions 

A VSR protocol consists of one sender S and one receiver R. Suppose the victim (sender S) has a 
universal set T of files, each with a unique file identifier fid G {0, 1}*. Let M G {0, 1}* be the content 
of the file to be transferred from S to R. Suppose S and R have agreed on a default segment size in the 
initial TCP handshake of a usual TCP connection (as specified in RFC 793 |[22l ) such that the file content 
M is divided to fill n equally-sized segments s, G {0, 1}* indexed by i where 1 < i < n. Each s, consists 
of a 40-byte TCP header hi and an /-byte message payload mi, that is, Sj = hi\\rrii (where || denotes 
concatenation). Note that the sequence number of the TCP segment Sj is (i — 1) • I + ISN + offset 
where ISN is the initial sequence number of a TCP connection and offset accounts for the bytes 
used in connection initiation. What we actually demonstrate is that segment indices (used in this paper) 
and sequence numbers in a normal TCP connection are interchangeably convertible to each other; we 
will stick to using segment indices in the discussion of this paper. Without loss of generality, assume 
M = mi 1 1 • • • | \rrii \ \ ■ ■ ■ \ \m n Q A VSR protocol consists of the following algorithms. 

Setup (setup). setup(l A ) — > param takes the security parameter A and outputs the public parameters 

par am (such as the hash function and its size) used in the VSR protocol. 
Key Generation (KG). Let KG(1 X , param, n) — > sk be a probabilistic algorithm which generates the 

secret key sk. Note that in some VSR protocols (such as the hash-based protocol in Section |3~TT) . a 

secret key may not be needed and KG will not be invoked. 
Tag Generation (TG). TG(param, sk, i, Sj) — > ti is a probabilistic algorithm taking a TCP segment Sj 

(with its index i) and the sender secret key sk to generate a tag ti appended to Sj. That is, (sj, ti) is 

sent to the receiver R and the actual TCP segment sent is of the form Sj||£j. 



Note that sk is included in the definition of TG for generality to cover both cases: schemes using a 
secret key and schemes using no secret key. In schemes wherein a secret key is not used, ti merely is 
a random string; whereas, ti includes a random string and a keyed authenticator in schemes using a 
secret key. 

Proof Generation (PG). Let I C [l,n]. Denote {si : i G 1} by 5(1) and {U : i G 1} by T(I). Then 
PG(param, 1, 5(J), T(J)) — » p(I) is a deterministic algorithm used by the receiver R to generate 
a proof p(I) to convince the sender S that all TCP segments in S(I) have been received. (I,p(I)) is 
returned along with the TCP acknowledgement to the S. 

PG and p(J) are so defined based on / for the sake of generality such that both normal TCP (with 
cumulative acknowledgements [22]) and TCP-SACK (selective acknowledgement option |[T9l ) are 
covered. For TCP with cumulative acknowledgements li22l . each / is of the form {1, 2, r} where 
r is the index of the last in-sequence segment received correctly. 
Proof Verification (PV). PV(param,I,T(I),p(I)) — > 0/1 is a deterministic algorithm to check the 
correctness of the proof p(I). If correct, 1 is returned, meaning all segments in I has been received 
by the prover/receiver R. 

Note that the set of tags T{I) may or may not be needed in some constructions; for instance, the hash 
based protocol in Section 13.11 needs tags as input to the verification algorithm while the aggregate 
authenticator based protocol in Section [3^21 does not need tags for proof verification. 

3 In case \M\ is not an integral multiple of \rrii\, m n would be padded with zeros. 



Since par am is public and part of the input to all algorithms in a VSR protocol, we will not explicitly 
write it as algorithm input in this paper. 

2.2 Security Notions 

As a basic requirement, a VSR protocol needs to satisfy the correctness property stated as follows. 

Correctness. For all files with content M G {0, 1}*, all choices of secret key sk, and all / C [0, n], if 
Si is a valid and correctly indexed segment from M and ti <— TG(sk, i, si) for all i E I, then 

PV(/,T(/),PG(/,<S(/),T(/))) = 1. 

We have three notions for the security (or soundness) of a VSR protocol, the first one (security against 
known file content and tag access attacks) being the strongest notion but might not be achievable. The 
second one (security against known file content only attacks) could be the default one which reasonably 
fits real world scenarios. 

Four types of oracle queries (adversary interaction with the system) are allowed in the security model, 
namely, the playback oracle Opp, the segment query oracle Osq, the tag access oracle Ota and the 
proof verification oracle Opy- Their details are as follows: 

Playback Oracle Opp(fid, I). On input a playback oracle query (fid, I), the playback oracle retrieves 
the file with identifier fid and content M G {0, 1}* and breaks down M into Z-byte units to fill a 
number of (say n) segments Sj where 1 < i < n; the TCP headers are determined by emulating the 
initiation of a new TCP session. The playback oracle then generates the secret key sk by running KG 
and computes tags ti = TG(,sA;, i, Si) for all i G [1, n], and replies with {(sj, U) : 1 < i < n}. 

Segment Query Oracle 0sg(i). For a current and established TCP session (with fixed default segment 
size / and fixed total number n of segments for a file with identifier fid and content M), for fixed 
secret key and segment decomposition, on input a segment query (i) (where 1 < i < n), the segment 
query oracle retrieves the segment s^ and the secret key sk and runs the tag generation algorithm TG 
to generate the tag ti = TG(sfc, i, si) and sends (sj, ti) as the reply. 

Tag Access Oracle OrA(i)- For a current and established TCP session (with fixed default segment size 
I and fixed total number n of segments for a file with identifier fid and content M), for fixed secret 
key and segment decomposition, on input a tag access oracle query (i) (where 1 < % < n), the tag 
access oracle retrieves the segment Sj and the secret key sk and runs the tag generation algorithm TG 
to generate the tag and sends the result TG(sk, i, Si) as the reply. 

Proof Verification Oracle Opy(I, p(I)). For a current and established TCP session (with fixed default 
segment size I and fixed total number n of segments for a file with identifier fid and content M), 
for fixed secret key and segment decomposition, on input a proof verification oracle query (I,p(I)) 
(where / C [1, n]), the proof verification oracle runs PV and relays the result (0 or 1) back. 

Normally, the playback oracle is accessed by an adversary before launching the actual attack session 
while the segment query and tag access oracles are usually accessed in the actual attack session. The 
playback oracle is to model the scenario that an adversary first accesses victim websites (by honestly 
following the TCP congestion control algorithm and sending back correct feedback) to learn their be- 
havior and obtain a number of large files (along with the used TCP headers and VSR tags) and stores 
this information as references for launching the subsequent actual attack. We believe the playback attack 
would be a real threat in misbehaving TCP receiver attacks. 



The difference between the segment query oracle and the tag access oracle is in the reply content: an 
adversary can only obtain a tag along with the corresponding segment in a segment query, whereas, an 
adversary can obtain (via some unknown means such as a man-in-the-middle attack) just the tag (without 
a segment) of a lost TCP segment in a tag access query. 

Recall that the goal of a VSR protocol is to ensure that a TCP receiver cannot deceive a TCP sender 
into believing that it has received a TCP segment which is actually lost in the network. The segment 
query oracle models the usual networking environment in which a TCP receiver would receive most of 
the transmitted TCP segments (and their VSR tags) while a small portion of them may be dropped at 
the input queues of congested routers enroute; the replies of the segment query oracle represent received 
TCP segments along with their VSR tags in a normal operating scenario. In the normal situation, it 
is implicitly assumed that the tags for all lost segments will not be accessible to a TCP receiver; this 
assumption could be reasonable since when a TCP segment (more precisely, an IP datagram) is dropped 
at a congested router, there is no way for a TCP receiver to learn the tag of that TCP segment which 
has never arrived at the receiver unless there is some out-of-band channel accessible to the receiver0 
Nevertheless, for completeness, in our model, we include a tag access oracle to provide tags of lost 
segments for an adversary. Note that the tag access oracle can be treated as some form of man-in-the- 
middle attacks in narrow sense. The middle man in a man-in-the-middle attack could perform various 
computation on a set of captured TCP segments and their VSR tags and pass the result of computation 
to the attacker while a tag access oracle only detaches the tag from a captured TCP segment and passes 
the tag to the attacker. 

Security against Known File Content and Tag Access Attacks (KFC-TA-secure). To define VSR 
security against know file content and tag access attacks (KFC-TA attacks), we use the following game 
played between a challenger and an adversary. If no PPT (Probabilistic, Polynomial Time) adversary can 
win the game with non-negligible advantage (as defined below), we say the VSR protocol is KFC-TA- 
secure. 

Definition 1. A VSR protocol is secure against known file content and tag access attacks (i.e. KFC-TA- 
secure) if the advantage of winning the following game is negligible in the security parameter Xfor all 
PPT adversaries. 

Setup. The challenger runs setup to generate the public parameters par am and gives par am to the 
adversary. 

Query 1. The adversary can issue to the challenger any playback queries on file fidj and default seg- 
ment size lj of his choice. Assuming the file content Mj is broken down to fill nj segments, the 
challenger picks a new secret key skj (if needed in the protocol) by running KG and responds with 
{(sji, TG(skj,i, Sji)) : 1 < i < rij}; that is, the adversary obtains the set of all TCP segments and 
VSR tags for the transfer of file fid. The adversary is allowed to make nested queries of segment 
queries, tag access queries and proof verification queries in each playback query. Denote the set of 
queried file identifiers in Query 1 phase by T\. 

Challenge. Once the adversary decides that the first query phase is over, it selects a file identifier fid 
and a default segment size / to ask the challenger for a challenge TCP session. There is no constraint 
imposed on the choice of file. Denote the file content of fid by M . The challenger runs standard 
TCP initiation handshake with the adversary and determines TCP headers to be used. The challenger 
generates a new secret key sk (if needed in the protocol) and breaks down M to fill say n TCP 



4 For instance, the misbehaving TCP receiver installs some agents close to the sender to grab the tag of a TCP segment before 
it is dropped by a router and to send him just the tag. 



segments. The adversary is challenged with the task of creating a correct proof for TCP segments he 
has not queried in the second query phase. 

Query 2. The adversary is allowed to make more queries to all oracles as previously done in Query 1 
phase except proof verification queries on the challenged TCP session unless the reply result is 
Playback queries on the challenge fid is even allowed; note that, for playback queries, even the same 
file identifier (as the challenge TCP session) is requested, a different secret key and random coin will 
be used for the new query session (as described in the playback oracle). Denote the set of indices for 
Osq and Ota queries on the challenged TCP session by Z$q and Tta respectively. Let the set of 
queried file identifiers fidj in Query 2 phase be JF 2 . 

Guess. Finally, the adversary outputs a guess (J, p(I)) for some I C [1, n] such that I\Isq 7^ (where 
<p is the empty set). 

Result. The adversary wins the game if (I,p(I)) passes the verification test PV. The advantage Adv^ 
of the adversary A is defined as the probability of winning the game. 

Security against Known File Content Only Attacks (KFC-secure). VSR security against known file 
content attacks is defined by the same game in Definition Q] except that no tag access (Ota) queries can 
be made on the challenge TCP session in Query 2 phase. That is, Tta = 4>- 

Security against Tag Access Only Attacks (TA-secure). VSR security against tag access only attacks 
is again defined by the same game in Definition Q] except two modifications as depicted below. 

1. In the Challenge phase, the adversary has to choose a challenge fid ^ T\, that is, fid has to be a 
new file identifier not used as input for the playback queries in the Query 1 phase. 

2. In the Query 2 phase, the adversary can only make playback queries on fidj ^ fid where fid is the 
file identifier for the challenge TCP session. That is, fid T%. 

3 Constructions of Verifiable Segment Receipt Protocol 

Two constructions of a VSR protocol are given in this section, one based on an ideal cryptographic hash 
function and the other based on an aggregate authentication introduced in Q. An ideal cryptographic 
hash function is one which behaves like a truly random function the output of which is unpredictable 
even though some bits of the input are known lPT2l . An aggregate authenticator assures the integrity of 
messages while allowing (additive) aggregation to be performed separately on messages and tags. 

3.1 VSR Construction based on an Ideal Cryptographic Hash Function (VSR-H) 

The VSR-H protocol is based on the scheme originally proposed by Savage et. al. l25ll . In their scheme, a 
random number is appended to each TCP segment sent and the receiver returns the sum of these random 
numbers (as a proof of receipt of a chuck of TCP segments) to the sender. Since these random numbers 
are independently picked regardless of the content of the TCP segments, it is non-trivial to tell whether 
the receipt of a random number in the tag is equivalent to the receipt of the corresponding TCP segment; 
it is vulnerable to tag access attacks. In fact, it can be shown that the Savage's scheme is only KFC-secure 
but not TA-secure. 

In the hash based VSR construction, we modify the Savage's scheme to ensure that the proof gener- 
ated by a receiver is message-dependent using a hash function. The VSR-H protocol is both KFC-secure 



5 A TCP sender should terminate a TCP session when an incorrect proof is received from the receiver. 



and TA-secure assuming the hash function behaves like a truly random function [12]. Informally, a truly 
random function h is a deterministic function with unpredictable outputs in the sense that, for each new 
input (whose output from h is yet to be evaluated), its output is indistinguishable from a randomly picked 
number from the range of h. Collision-resistance is also implicitly implied by the indistinguishability 
property. Of course, for each of the previously evaluated inputs, the same output will be obtained for all 
invocations of h since h is deterministic. Ideally, behaving like a truly random function is the design goal 
of all cryptographic hash functions. 

We should emphasize that we do not make use of the random oracle model [5] in our proof of 
security for the VSR-H protocol. More specifically, we do not limit the number of hash invocations by 
the adversary as in the usual random oracle model; what limits the number of hash evaluations (on the 
targeted TCP session) by the adversary in our case is the number of hash inputs known to the adversary. 
In our case, the challenge for the adversary is that it has to find the hash output for an incomplete input 
(with part of the input bits unknown). Neither does our proof manipulate the adversary through the hash 
function. 

Suppose the arithmetics is done in some finite group G where G could be any group of integers 
mod N (where N is an arbitrary integer not necessarily prime) or any extension fields of F2. Normally, 
only addition would be used in the VSR-H construction. When F2»™ (for some integer m) is used, an 
addition operation can simply be done by bitwise-XOR (exclusive OR). 

The operations of the VSR-H protocol work as follows. 



VSR Protocol based on an Ideal Cryptographic Hash Function (VSR-H) 

Assume the file being transferred can be broken down to fill in a total of n TCP segments indexed by i. 
Setup (setup): 

For a security parameter A, choose a hash function h : {0, 1}* — » Zjv where N has to be at least A bits long. 
Let h be an ideal cryptographic hash function. 

Key Generation ( KG): 

No secret key is needed in this protocol. 

Tag Generation ( TG) by S: 
For each TCP segment Si, 

1. randomly pick a new string n S {0, 1} A ; 

2. compute Xi = h(r\\si) and store (i, Xj) in a list L x ; 

3. output n as U for the segment Sj. (sj, ti) is sent to the receiver. 

Proof Generation (PG) by R: 

To generate a proof for the receipt of all segments with indices in I, 

1. for each i 6 J, retrieve (si,tj) and compute yi = h(ti\\si); 

2. compute the proof p(I) as p(I) = yi mod N. 

Proof Verification (PV) by S: 

Given a proof (I,p'(I)), the verification is performed as follows. 

1. For all i £/, retrieve Xi from L x . 

2. Compute the sum P — Xi mod N. 

3. Check p'(I) = P. If yes, return 1, otherwise, return 0. 



The security of the VSR-H protocol is summarized by the following theorem. 

Theorem 1. Assuming h behaves like a truly random function, the VSR-H protocol is both KFC-secure 
and TA-secure. 

Proof. The proofs of KFC-security and TA-security for VSR-H can be done using a similar set of argu- 
ments; we will focus on the proof of KFC-security. The proof is based on a contrapositive argument that 
if there exists an adversary A which can break the VSR-H protocol with non-negligible probability, an 
algorithm A' can be constructed from A to determine a correct output of h on a new input not previously 
evaluated on with non-negligible probability. Note that the ability to determine an output of h on a new 
input already breaks the indistinguishability property of h. 

An outline of the construction of A' is as follows: A' runs setup and gives par am to A. A' answers 
all three types of queries (Opb, Osq, Ota) from A by randomly picking the tag rji and the file content 
Mj. A' can answer verification queries by asking its own challenger to evaluate h. Once A outputs a 
challenge request, A' randomly picks a file with content M and passes M to A. When A outputs a result 
(I, p(I)), A' randomly picks ijsj G / such that the corresponding input to h has not be previously queried 
to its challenger. A' makes h queries to determine the hashed values for all ij± ^ lA'^A G I- Subtracting 
these hash values from p(I), A' can determine h(si , ||r» .,) where the Sj | |r*< , is a new input with no 
previous h made before. 

If A is a polynomial time algorithm, so is A'. If *4's output (I,p(I)) can pass the verification test, 
then the determined h(si , \ \r% , ) has to be a correct output of h. A' can determine h{si A , | |r*< , ) correctly 
with non-negligibly probability if A can break the security of VSR-H with non-negligible probability. 

Regarding playback queries, even for the same file content, the inputs to h for evaluation are different 
from session to session due to a freshly picked random tag. Note that the form of input to h for a segment 
Sji in session j is Sji\\rji where rji is freshly picked. It may be easy for an adversary to determine Sji. 
But given all tuples of (sji , , h(sji | \rji)), it is still hard to determine h(si \\n) with negligible error for 
the challenge session with unknown r, unless the cardinality of the set {/t(a;||r) : Vr € {0, 1} A } (for 
some known x) is not large enough. If this is the case, h is no longer collision-resistant and hence cannot 
be a truly random function. X 

Practical Considerations. For the VSH-H protocol to achieve 2 80 security, A needs to be at least 80 
bits, that is, the random strings 7-j's and the hash function h need to be 80-bit long. In other words, each 
tag or proof needs to be 80-bit long. 

3.2 VSR Construction based on an Aggregate Authenticator (VSR-AA) 

Our second VSR protocol is constructed based on an (additive) aggregate authenticator [7 ] which al- 
lows aggregation on messages and aggregation on tags. In turns, the aggregate authenticator in Q is 
constructed from a pseudorandom function (PRF) II 141 1 3TI . For an in-depth treatment of PRFs lTT4l . we 
refer to lfl2l . In our context, a PRF is needed to derive secret keys for different TCP segments from TCP 
session keys (freshly picked for each new TCP session). 

Let F = {F x }xeN be a PRF family where F x = {f s : {0, 1} A -> {0, l} A } se{0 ,i}A is a collection 
of function^] indexed by key s G {0, 1} A . Informally, given a function f s from a PRF family with an 
unknown key s, any PPT distinguishing procedure allowed to get the values of / s (-) at (polynomially 

6 While we denote both the input and the secret key of / with the same length, they need not have the same length in PRFs, 
namely, we can have a PRF of the form: / : {0, 1} A x {0, 1} ' — > {0, where the key length is A, input length is U and 
output length is l . 



many) arguments of its choice should be unable to distinguish (with non-negligible advantage in A) 
whether the answer of a new query is supplied by f s or randomly chosen from {0, 1} A . The VSR-AA 
protocol is both KFC-secure and TA-secure if the underlying / is a pseudorandom function. 

The arithmetics for the VSR-AA protocol is done in some finite field 7L V where p is some large prime 
(at least A-bit long). Alternatively, the extension field of Z2 can be used; the advantage is that extension 
fields of Z 2 can usually result in efficient logic circuits and efficient computation procedures on most 
platforms. 

A hash function h : {0, 1}* — > Z p is used in the VSR-AA protocol. Unlike the hash function in VSR- 
H, the hash function used in VSR-AA is merely for the mapping purpose (mapping an arbitrary binary 
string to an element in Z p ) and no security requirement is thus needed. In the case the segment size is a 
multiple of \p\ (the length of p), h can simply be implemented by breaking down the input segment into 
units of length \p\ (each of which can be represented as an element in Z p ) and summing up all these units 
in Z p and treating the sum as the output of h. 

The operations of the VSR-AA protocol work as follows. 



VSR Protocol based on an Aggregate Authenticator (VSR-AA) 



Assume the file being transferred can be broken down to fill in a total of n TCP segments indexed by i. 
Setup (setup): 

For a security parameter A, choose a large prime p where p has to be at least A bits long. Choose a pseudorandom 
function / : {0, 1} A x {0, 1}* -> Z p (with key length A). Let h : {0, 1}* -> Z p be a chosen length-matching 
function. 

Key Generation ( KG) by S: 

Randomly choose two keys K £ Z* and K' € Z*. K' is the session key used to derive segment keys while K 
is used as a long term segment key. 

Tag Generation (TG) by S: 

For each TCP segment Si with index i, 

1. retrieve the session keys K, K'; 

2. generate a new segment key ki by computing ki = f K i (i); 

3. compute the tag U = K ■ h(si) + fa mod p; 

4. (si, ti) is sent to the receiver. 

Proof Generation ( PG) by R: 

To generate a proof for the receipt of all segments with indices in I, 

1. for each i 6 I, retrieve (si,ti); 

2. compute x — M s m °d P> 

3. compute y = J^igi m °d P> 

4. output (x, y) as the proof p(I). 

Proof Verification (PV) by S: 

Given a proof (J, x'y'), the verification is performed as follows. 

1. Retrieve the session keys K, K'; 

2. Compute Kj = J2 ie i fx' (*) mod P- 

3. Check y' = K 1 + K ■ x' mod p. If yes, return 1, otherwise, return 0. 



The security of the VSR-AA is based on the difficulty in determining the actual coefficients used in 
an under-determined equations. More specifically, given x and y where y = K' + K ■ x for fixed, secret 
K and K', determine the actual K and K' used in forming x and y. If K and K' are randomly picked, 
it can be shown that (x, y) does not give sufficient information to determine K, K'. For arithmetics 
in Z p , there are p possible 2-tuples of (k, k') which can lead to the given (x, y); only one out of p is 
the actual pair (K, K'). Hence, for a large enough prime, there is a negligibly small probability 1/p to 
guess (K, K') correctly. Nevertheless, this problem can be solved with ease if an adversary breaking the 
VSR-AA protocol exists. The idea is as follows. 

Suppose we are given a pair (x, y) and asked to determine the actual K, K' used. Without loss of 
generality, assume a single segment in the following discussion. This (x, y) can be treated as the expected 
receipt proof (h(s.i),ti) for a segment-tag pair (sj, ij) sent out to the receiver^ In order to lie about the 
receipt of a pair (si,ti) which is actually lost, in order to convince the sender, the receiver needs to 
determine a 2-tuple (V, y') to fulfil the constraint equation: 

y' = K' + K ■ x' (1) 

where K and K' are unknown. Note also that the receiver has no knowledge about (x, y). 

There are p possible 2-tuples of (x', y') fulfilling equation £0), one of which is (x, y). Suppose the 
tuple (x', y') fulfills equation (Q~|). The probability that (a/, y') ^ (x, y) is « l (for large p). In other 
words, we have two independent equations: (1) y' = K' + K ■ x' ; (2) y = K' + K ■ x to solve K and 
K' which is easy. Consequently, we can say the VSR-AA protocol is secure. A more rigorous argument 
is given in the proof. 

The security of the VSR-AA protocol is summarized by the following theorem. 

Theorem 2. Assuming f is a pseudorandom function, the VSR-AA protocol is both KFC-secure and 
TA-secure. 

Proof. Assume the PRF has some indistinguishability property as usual. We prove by contradiction, 
showing that a PPT adversary which can forge a valid pair (x',y') (recall that (x',y') = (x,y) with 
probability 1/p) can also break the indistinguishability property of the underlying PRF. We show the 
reductioro in two steps: first, we show that a forging algorithm to find (x 1 , y 1 ) can be used as a sub- 
routine to solve a newly defined problem called "Under-determined Equation Set with Pseudorandom 
Unknowns (UESPU)"; then we show that the UESPU problem is computationally hard if the underlying 
PRF has the usual indistinguishability property. The UESPU problem is defined as follows: 

Under-determined Equation Set with Pseudorandom Unknowns (UESPU) Problem — Suppose K, K' 
are independent random seeds. Denote K\ as the sum ^2 ieI fK'(i) Given a 2-tuple (x, y) where y = 
K'j + K ■ x, find (K, Kj) while allowed to evaluate the PRF at any input i /. 

Solving the UESPU problem using a forger of (x', y'). 

Suppose there exists a PPT adversary A which can forge a valid pair (x', y') to pass the VSR-AA 
proof verification test with probability pf. Using A as a subroutine, we can construct another algorithm 
A' to find (K, K'j) from (x, y) with probability ^y-Pf in any instance of the UESPU problem. Note that 
A' should be able to answer Ota and Osq queries from A for any i' $ I by passing the queries to its 

7 Note there is no need to find Si such that h(si) = x although it is possible, (sj, U) will not be sent to the receiver who tries 
to lie about the receipt of it. 

8 The reduction of the problem of breaking the indistinguishability of the PRF to the problem of forging a valid (x', y') pair 
to pass the verification while (x, y) is not received. 



own challenger. Note that A' can answer all Opb and Opy queries without external help. For playback 
queries, A' can simply pick new seed keys to run a new session. 

The construction of A 1 is as follows: Give A the pair (x, y). When A returns a pair (x' , y') ^ (x, y), 
we can determine K, K\ from the resulting set of equations. The explanation is as follows: 
Note that 

y = K'j + K ■ x. 

So we have one equations and 2 unknowns. If (x 1 ', y') is a valid forgery, then it must satisfy the following 
two equations (with the same K, K'j) in order to pass the verification test: 

y' = K'j + K ■ x'. 

The pair (a/, y') adds in one new, independent equation. Since [x\ y') ^ (x, y) with probability 
it can be assured that the two equations are independent with high probability for large p. Hence, there 
are two independent equations and two unknowns in total and it should be easy to solve for K, K'j (a con- 
tradiction to the UESPU assumption). The probability of solving the problem in the UESPU assumption 
is hence ^-p/. 

A distinguisher for the PRF using an algorithm which solves the UESPU problem. 

The UESPU problem is hard if K, K'j are generated by a PRF. There are one equation and two 
unknowns which cannot be uniquely determined. It could be shown that if there exists an algorithm A' 
solving in poly-time K and K \ from x and y, then the indistinguishability property of the underlying 
PRF is broken. 

The idea is as follows: assume the seed key for generating K'j is unknown and the key K is known. 
When a challenge K'j is received, we have to determine whether it is randomly picked from a uniform 
distribution or generated by the PRF with an unknown seed key. We compute y = K'j + K ■ x to A'. If 
the solution from A' does not match the generated K'j, we reply that K'j is randomly picked, otherwise, 
it is generated from the PRF. If A' has non-negligible probability of breaking the UESPU assumption, 
the above construction would also has a non-negligible advantage of breaking the indistinguishability 
property of the underlying PRF. Note that all queries from A' could be answered by sending queries to 
the challenger and running the PRF with the known key. & 

Practical Considerations. For the VSH-AA protocol to achieve 2 80 security, p and hence A need to be 
at least 80 bits. That is, each tag is 80-bit long and each proof is 160-bit long. 

Most provably secure PRFs such as rf2~T1 are based on the hardness of certain number-theoretic prob- 
lems. However, such constructions are usually computationally expensive. Instead, key derivation in 
practice is often based on functions with conjectured or assumed pseudorandomness, i.e., it is inherently 
assumed in the construction rather than proven to follow from the hardness of a computational problem. 
One common example is the use of cryptographic hash functions for key derivation such as ll27l . Some 
well-known primitives, such as HMAC [4] and OMAC |[T5l (conjectured PRFs), are based on assumed 
pseudorandomness. (HMAC assumes that the underlying compression function of the hash function in 
use is a PRF, while OMAC assumes the underlying block cipher is a pseudorandom permutation.) 

The VSR-AA protocol in this paper does not impose a restriction on the type of underlying PRFs. 
The security guarantee provided by the proposed construction holds as long as the underlying PRF has 
the property of pseudorandomness or indistinguishability. We note that the aforementioned pseudoran- 
domness property is also a basic requirement for the hash function used for key derivation purposes 
H27I41 . e.g., in the well-known IPSec standard. 



3.3 Overhead 



Assume A is the used security parameter, that is, the hash function in VSR-H is A bits long and p in 
VSR-AA is also A bits long. 

Let t a dd an d tmuiu denote the respective costs of performing a A-bit addition and multiplication in 7L p . 
Note that t a dd ~ 0(A) while t mu iu ~ 0(X 2 ) (See [20] Chapter 2). Let t pr f denote the cost of evaluating 
the PRF plus the hash function in VSR-AA and th denote the cost of evaluating the hash function in 
VSR-H, both with security parameter A. Note that the cost of evaluating h in VSR-AA is negligible 
compared to that of evaluating the PRF. Note also that the actual computational cost of evaluating a 
typical cryptographic hash function in VSR-H usually depends on the size of the input string but is 
proportional to the output size which is the security parameter A here. 

Let S and R denote the sender and receiver respectively. Let w be the maximum window size (in 
number of segments) for a TCP connection. The overhead of the two VSR protocols is summarized as 
follows. 





VSR-H 


VSR-AA 


Storage (S) 

Computation Overhead (Tag Generation) per Segment (S) 
Computation Overhead (Tag Verification) per Window (S) 
Communication Overhead per Segment Sent (S) 


w ■ A 

t h 

(w - 1) • t add 
A 




tprf "t - t a dd ~\~ tmulti 
W ■ (tprf + tadd) + t mu lti 
A 


Computation Overhead (Proof Generation) per Window (R) 
Communication Overhead per Window (R) 


W ■ th + (W — 1) • tadd 
A 


2(W - 1) • tadd 
2A 



Table 1. Overhead of the VSR protocols (assuming |/| = w). 



Both VSR-H and VSR-AA have the same overhead size for sending each TCP segment which is A 
bits. For 2 80 security, it translates to a tag size of 80 bits or 10 bytes. As specified in RFC 879 11231 . the 
MTU (Minimum Transmission Unit) of an IP (Internet Protocol) datagram is 576 bytes. This corresponds 
to a minimum TCP payload size of 536 bytes (after subtracting the 20 bytes IP header and 20 bytes TCP 
header). As a result, the maximum communication overhead for embedding VSR tags (for both VSR-H 
and VSR-AA) is 10/536 « 1.86%. 

4 Defending Man-in-the-Middle Attacks 

The VSR-AA protocol can be modified to partially solve the man-in-the middle attacks. The variants are 
designed to ensure some designated entity is needed to help the receiver to generate a correct segment 
receipt proof. We give two variants (based on two different intuitions), the first one (VSR-AA-MAV) 
requiring a well-trusted network entity geographically close to the receiver to help the receiver in gener- 
ating an acceptable proof whereas the second one (VSR-AA-RPK) involving the receiver's public key. 

In the first variant, the trusted entity could be the gateway or firewall of the local domain wherein 
the receiver is attached to. We call this trusted network entity the middle-address-verifier as its task is 
to assure that the receiver is really at the network address it claims. The sender shares a secret session 
key Kg with the gateway which needs to do some processing on the VSR tags to allow the generation 
of segment receipt proof acceptable by the sender. The processing is seamless to the receiver which only 
needs to follow the VSR-AA protocol. 

In the second variant, the public key of the receiver is needed in the VSR tag generation by the sender. 
The receiver needs to use its private key to generate a correct proof acceptable by the sender. We intend 
to include the private key operation in the processing of each segment at the receiver to be certain that 
the only way a malicious receiver can gain through installed agents close to the sender is to give out its 
private key to the agents. For the receiver, launching such a man-in-the middle attack could be risky as 



once his installed agents are detected and compromised, his own private key will be revealed or made 
public. Of course, we assume there is some binding between network addresses and public keys. 

4. 1 VSR-AA Protocol with Middle Address Verifier (VSR-AA-MAV) 



VSR-AA Protocol with a Private Key Middle- Address- Verifier 



Assume the file being transferred can be broken down to fill in a total of n TCP segments indexed by i. 
Setup (setup): 

For a security parameter A, choose a large prime p where p has to be at least A bits long. Choose a pseudorandom 
function / : {0, 1} A x {0, 1}* — ► Z p . Let h : {0, 1}* — > Z p be a chosen length-matching function. 

Key Generation ( KG): 

Randomly choose two keys K G Z* and K' G Z*. K' is the session key used to derive segment keys while K 
is used as a long term segment key. Generate a new secret key Kg to be shared with middle-address-verifier. 
Assume the sender shares Kg with the trusted middle-address-verifier. 

Tag Generation ( TG): 

For each TCP segment Si with index i, 

1. generate a new segment key ki by computing ki = f K i (i); 

2. generate a new middle-address-verifier key gi by computing gi = /k g (i); 

3. compute the tag t'i = (K ■ h(si) + ki) ■ gi mod p; 

4. (si,t'i) is sent to the receiver. 

Processing by the Middle-Address-Verifier: 

For each TCP segment-tag pair (si,t'i) with index i received, the middle-address-verifier performs the fol- 
lowing processing. 

1. Compute (ft = fK G {i). 

2. Compute U = tl ■ g^ 1 mod p. 

3. Pass (si,ti) to the receiver. 

Proof Generation (PG): 

To generate a proof for the receipt of all segments with indices in I, 

1. for each i £ I, retrieve (si, U)\ 

2. compute x = ~}2 ieI h(si) mod p; 

3. compute y — ~}2 ieI U mod p; 

4. output (x, y) as the proof p(I). 

Proof Verification ( PV): 

Given a proof (I, x'y'), the verification is performed as follows. 

1. Compute Ki = J2iei fx' (*) m °d P- 

2. Check y' = Ki + K • x' mod p. If yes, return 1, otherwise, return 0. 



The security of this variant is summarized as follows. 



Theorem 3. Suppose the malicious TCP receiver can obtain gi 's for different i of his choice for the 
challenge session except those i € / where I is the challenge set. Assuming f is a pseudorandom 
function, the VSR-AA protocol with middle-address-verifier is both KFC-secure and TA-secure in the 



presence of all man-in-the-middle attacks wherein all installed malicious agents are not closer ( on the 
route along which the TCP segments in I transverse) to the receiver than the middle-address-verifier. 

4.2 VSR-AA Protocol using Receiver Public Key (VSR-AA-RPK) 



VSR-AA Protocol with Public Key Verifier 



Assume the file being transferred can be broken down to fill in a total of n TCP segments indexed by i, Suppose 
the receiver uses the public key system based on ElGamal 1 10], that is, (g, PK) is the public key of the receiver 
where g is secure generator for Z* v and PK — g s for some unknown secret key s and s is kept secret by the 
receiver. 

Setup (setup): 

For a security parameter A, choose a large prime p where p has to be at least A bits long. Choose a pseudorandom 
function / : {0, 1} A x {0, 1}* — > Z p . Let h : {0, 1}* — > Z p be a chosen length-matching function. 

Key Generation ( KG): 

Randomly choose two keys K 6 Z* and K' £ Z*. K' is the session key used to derive segment keys while K 
is used as a long term segment key. 

Tag Generation ( TG): 

For each TCP segment Si with index i, 

1. generate a new segment key ki by computing ki = f K i (i); 

2. pick a random r.; g Z* and compute Ui = g Ti mod p; 

3. compute the tag ti = (K ■ h(si) + ki) ■ PK Ti mod p; 

4. (si,ti,Ui) is sent to the receiver. 

Proof Generation (PG): 

Given the receiver private key s, to generate a proof for the receipt of all segments with indices in /, 

1 . for each i 6 I, retrieve (si,ti,Ui); 

2. compute «; = ul mod p 

3. compute x = X^igi M s m °d p; 

4. compute y — ti ■ v" 1 mod p\ 

5. output (x, y) as the proof p(I). 

Proof Verification ( PV): 

Given a proof (7, x'y 1 ), the verification is performed as follows. 

1. Compute Ki = Ik' (i) mod p. 

2. Check y = Ki + K ■ x mod p. If yes, return 1, otherwise, return 0. 



The security of this variant is summarized as follows. 

Theorem 4. Assuming f is a pseudorandom function and the computational Diffie-Hellman problem is 
hard [20 1, the VSR-AA protocol using the receiver's public key is both KFC-secure and TA-secure if 
the receiver does not give out its private key, that is, only the receiver ( designated by the corresponding 
public key) can generate a valid segment receipt proof. 

5 Conclusions 

We address the problem of misbehaving TCP receivers which lie about the receipt of TCP segments 
not actually received in order to cause congestion collapse in the Internet. Our solutions are based on 



cryptographic tools, namely, an ideal cryptographic hash function behaving like a random function and 
an aggregate authenticator constructed based on a pseudorandom function. The protocols proposed are 
provably secure and reasonably efficient for incorporation into the TCP protocol. We also give two vari- 
ants (of the protocol based on aggregate authenticator) to partially solve the main-in-the-middle attack 
problem, which was largely unaddressed before. 
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